FIG. 1 is a schematic illustration of a communication system 100 implemented over a packet-based network such as the Internet 108 comprising a plurality of interconnected elements. Each network element is connected to the rest of the Internet 108, and is configured to communicate data with other such elements over the Internet by transmitting and receiving data in the form of Internet Protocol (IP) packets. Each element also has an associated IP address locating it within the Internet, and each packet includes a source and destination IP address in its header. The elements shown explicitly in FIG. 1 are: a plurality of end-user terminals 102(C) to 102(E) such as desktop or laptop PCs or Internet-enabled mobile phones; a server 104 of an Internet-based communication system; and a router 111 coupling to another network 110. However, it will of course be appreciated that many more elements make up the Internet than those explicitly shown. This is represented schematically in FIG. 1 by a communications cloud 108 which will include many other end-user terminals, servers and gateways, as well as routers of Internet service providers (ISPs) and Internet backbone routers.
Packet-based networks such as the Internet can be used to implement a number of different types of communication between end-users, such as voice-over-IP (VoIP) calls, video-over-IP calls, instant messaging (IM) chat sessions, and file transfer. To achieve this, each of a plurality of end-users installs and executes a client application on their respective terminal 102. The client applications together with any required functionality of server 104 form a communication system running over the Internet. Further, by communicating via a gateway to a telephone network (not shown), the system may also allow communication with other types of network such as a PSTN network in order to call a conventional fixed land-line or a mobile cellular network in order to call a mobile phone.
For example, voice-over-IP (VoIP) calls are beneficial to end-users because they are typically of significantly lower cost than fixed line or cellular mobile calls, often even free when from one VoIP client to another (rather than via a gateway to a telephone network). The cost savings may be particularly significant in the case of international or long-distance calls, because when communicating over the Internet using IP then the cost need not be dependent on distance. Similar comments may apply to video-over-IP calls.
In order to communicate with another client, the initiating client needs to know the IP address of the terminal 102 on which the other client is installed. Therefore a process of address look-up is required.
Some Internet-based communication systems are managed by an operator, in that they rely on one or more centralized, operator-run servers for address look-up (not shown). In that case, when one client is to communicate with another, then the initiating client must contact a centralized server run by the system operator to obtain the callee's IP address.
In contrast to these operator managed systems, another type of Internet-based communication system is known as a “peer-to-peer” (P2P) system. The idea behind peer-to-peer (P2P) systems is to devolve responsibility away from centralized operator servers and into the end-users' own terminals. In the least, this means responsibility for address look-up is devolved to end-user terminals like those labelled 102(C) to 102(E) in FIG. 1. Each user terminal 102 runs a P2P client application, and each such terminal forms a node of the P2P system. P2P address look-up works by distributing a database of IP addresses amongst a subgroup of the end-user nodes, termed herein “supernodes”. The database is a list which maps the usernames of all online or recently online users to the relevant IP addresses, such that the IP address can be determined given the username.
Each supernode acts as an IP address look-up point for a group of other nearby nodes, and its respective list contains the usernames and IP addresses of the nodes in that subgroup. The subgroup need not necessarily be “nearby” in terms of geographical location, but rather in terms of how directly connected the nodes are to the supernode (which may be related to geographical location). Each client will monitor certain factors of its respective terminal 102 such as constancy of IP address and up-time to determine whether it should become a supernode. If so, the IP address of the supernode is advertised to the client applications running on other nearby nodes, and the supernode gathers the IP addresses and usernames of those nearby nodes for its list. Then, instead of contacting a centralized server, the client on an initiating node will contact its supernode to look up the IP address of the other node. Referring to FIG. 1 for example, the client on one user node 102(C) may look up the IP address of another user node 102(D) from a further user node 102(E) which happens to have become a supernode (the user of the supernode need not be involved in the communication or be a contact of the two other users). If the contacted supernode does not have the required IP address in its list because its respective subgroup does not include said other node, then the querying node 102(C) may contact one or more other supernodes whose subgroups may include that other node 102(D) and thus determine the required address. In this way, the list mapping usernames to IP addresses is distributed amongst end-user nodes and no server is required for address look-up.
In addition to address look-up, a supplier of the P2P client application may choose to provide some additional, secondary features which in contrast to address look-up may involve a server 104. One such function is the distribution of authentication certificates which are supplied from the server 104 to the user terminals 102 when they first register with the P2P system. After initial registration, the users' clients can then exchange the certificates in order to authenticate each other without further involvement of a server. Further details on the use of digital certificates for authentication in an exemplary P2P system can be found in WO 2005/009019. The P2P server 104 may also be used to provide some other secondary features in relation to a P2P network, such as to host contact lists and/or “avatar” images (images chosen by the users to represent themselves graphically to others of the P2P network). Nonetheless, the primary function of address look-up is still handled in a distributed fashion by end-user nodes, not by a server.
Once known, the address allows a user to establish a voice or video call, or send an IM chat message or file transfer, etc. Additionally however, the address may also be used when the client itself needs to autonomously communicate information with another client. One example of this occurs when clients need to share presence information. Presence is an availability status of the user in question, preferably defined in part by that user themselves. For example, presence status may indicate that the user is offline, that the user is online and available, or that the user is online but has selected to be shown as unavailable (“do not disturb”).
The mechanism for handling presence depends on the relative network locations of the nodes involved. As mentioned, there may exist a separate, localized network 110 coupled to the Internet via a router 111. The local network 110 comprises a plurality of local end-user nodes 102′ such as desktop or laptop PCs. Two such nodes 102′(A) and 102′(B) are shown in FIG. 1 for illustrative purposes. The local network 110 is said to be “separate” from the Internet in the sense that it uses a different internal address space. Each local node 102′ is allocated a local address which identifies it internally within the local network 110 and thus allows communication within the local network. In order to communicate externally over the Internet 108, the router 111 therefore comprises an address translator 112 which is arranged to translate between the local address space of the local network 110 and the external IP address space of the Internet 108. Such a scheme or process may be referred to as Network Address Translation (NAT).
Usually, the local network 110 is identified externally over the Internet 108 by fewer external IP addresses than there are user nodes of that local network 110, such that an external IP address does not uniquely identify a node of the local network 110. That is, the local nodes 102′ are represented over the Internet 108 by fewer addresses than the number of those local nodes. Often the whole or a part of the local network 110 is identified over the Internet 108 by only a single external IP address. Thus an entire address space comprising a plurality of addresses is mapped to a single external IP address. In this sense, the address translator 112 could also be described as an address multiplexer (for outgoing packets) and de-multiplexer (for incoming packets). Techniques for such mapping are known in the art.
As mentioned, an IP packet contains a source and destination address in its header. Thus for an outgoing packet transmitted from a local node 102′ to an external node 102, the router 111 translates its source address from the local address space to the external IP address space. Reciprocally, for an incoming packet transmitted from an external node 102 to a local node 102′, the router 111 translates its destination address from the external address space to the local address space.
However, NAT breaks the IP model of end-to-end connectivity across the Internet and obscures the local network's internal structure, because all packets appear to external nodes as if they originated from the router 111. This has an impact on how presence updates are handled.
Generally, the presence process starts with searching for contacts' network addresses in the P2P network. As discussed, the addresses are kept in the distributed database which is divided between different supernodes. When the presence module in the client requests a search, the query is sent to the distributed database. Once the search reply comes back, the presence module sends a status request command to the specified address. If the contact is online, it responds with a reply indicating its status. If no reply is received, the contact is deemed to be offline.
As for the route that is selected to send the status request commands through the network, this depends on whether sending UDP (User Datagram Protocol) traffic directly to the target node is possible. If it is, the commands are sent directly to the node. However if the node is behind an NAT then the requests are routed to the target node through the supernode to which the target node belongs. Replies travel back using the same route.
So for example, if the client running on an external node 102(C) needs to know the presence status of one of the nodes 102(A) of the local network 110, then the status request is routed to it through the supernode 102(E). The response indicating the requested presence information also returns back via the supernode 102(E).